@tbroyer does this look right to you now?

Trying it locally (using npm add -D eslint-plugin-depend@file:../../e18e/eslint-plugin-depend, I have no idea how npm link actually works and whether it's/there's a better solution, it just scares me as I don't want any system-wide side effect), this still fails with the same error as in #43.

Changing the project to emit ESM (I added "type": "module" to the package.json and ran npm run build:js; eslint.config.js would have to be migrated to ESM or renamed to .cjs) makes it pass though. Given that Node 18 reaches EOL at the end of the month, maybe that's an acceptable change?

yep i actually opened #45 today and had meant to do it a few weeks ago but totally forgot

we can land that first in a new major and merge this afterwards maybe

Well, if you do that, there will be this TS error:

Type 'string' is not assignable to type 'InfiniteDepthConfigWithExtends'.

To reproduce, add on top of file // @ts-check

in ESLint 9, it works fine (it was introduced in 9.x)

in earlier versions of 9, and 8, you have to use a reference (depend.configs['flat/recommended'])

Hmmm, for me, I've figured this workaround:

import * as depend from "eslint-plugin-depend";

... and this:

  {
    name: "depend",
    ...depend.configs["flat/recommended"],
    rules: {
      "depend/ban-dependencies": [
        "error",
        {
          Allowed: ["lodash"],
        },
      ],
    },
  },

you can extends the reference:

extends: [
  depend.configs['flat/recommended']
]

Well, why is this better? And this causes another problem. For example, if I use

  {
    name: "depend",
    extends: [depend.configs["flat/recommended"]],
    rules: {
      "depend/ban-dependencies": [
        "error",
        {
          allowed: ["lodash"],
        },
      ],
    },
  },

then the ESLint inspector displays it twice, one time too much:

This happens when you use extend, but not when you use the spread operator.

IMO the question is not whether this is better or not (for some definition of "better" that'll probably be subjective), but whether this follows ESLint's own choices (whether you like it not).

ESLint's documentation uses defineConfig() and extends, so that's what an ESLint plugin should also use in its docs IMO.

And ESLint v8 was EOL'd back in october last year: https://eslint.org/blog/2024/09/eslint-v8-eol-version-support/